[アップデート] AWS CodePipeline の GitLab ソースプロバイダー使用時にグループプロジェクトも指定出来るようになりました

[アップデート] AWS CodePipeline の GitLab ソースプロバイダー使用時にグループプロジェクトも指定出来るようになりました

Clock Icon2023.09.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

ちょうど 1 ヶ月前 AWS CodePipeline が GitLab リポジトリをサポートしました。
CodePipeline のソースプロバイダーとして GitLab.com のプライベートリポジトリを指定出来るようになったというものです。

しかし、その時点では GitLab のユーザープロジェクトのみがサポートされており、グループプロジェクトはサポートされていませんでした。
組織で管理するワークロードは通常グループプロジェクトとして管理すると思いますので、実質本番ワークロードに採用するのが難しい状態でした。

しかし、先日のアップデートで CodePipeline で GitLab グループプロジェクトも使えるようになりました。

本日は実際にグループプロジェクトやサブグループプロジェクトを対象にパイラプラインを作成してみましたので手順などを紹介します。
ユーザープロジェクトと少し勝手の違う部分があったのでそのあたりも紹介したいと思います。

事前に GitLab 側に次のようにグループとサブグループを作成し、それぞれ適当なプロジェクトを 1 つづつ作成しています。

グループ

前回(冒頭の記事)に GitLab と AWS の接続を構成したので CodeStar 接続が存在しています。
今回はこちらをそのまま流用します。

ここで注意点があるのですが、リポジトリを検索しようとしてもユーザープロジェクトしかリストに表示されないと思います。

次の公式ドキュメントに記述されているのですが、グループプロジェクトの場合は名前空間からプロジェクト名まで手動での入力が必要な仕様となっています。

そこで、事前に GitLab 側で情報を取得しておきましょう。
グループ名ではなくて名前空間なので、次の例だとhogegroup/hogerepoではなくhogegroup2/hogerepoとなります。
URL から取得するのが良さそうです。

取得した値をリポジトリ名に直接入力します。
リポジトリパスの指定が正しければ次のようにブランチが選択出来るようになります。

一方で、リポジトリパスが誤っている場合は次のように「404 Project Not Found」が表示されます。

サブグループもサポートされている

公式ドキュメントに言及されていなかったのですが、検証してみたところ次のようにサブグループも問題なく指定することが出来ました。

試しに CodePipeline で単純に S3 へアーティファクトを出力するようにしてみたところ、グループもサブグループもそれぞれ出力されることが確認出来ました。

さいごに

本日は AWS CodePipeline の GitLab ソースプロバイダー使用時にグループプロジェクトも指定出来るようになったので使ってみました。

良いですね。ユーザープロジェクトのみだとかなり用途が限られるというか、ほとんど使えないかもと思っていたのでグループがサポートされたのは大きいですね。
前回、制限事項によって使用を見送っていた方はこれを機に再度検討してみては如何でしょうか。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.